Info-Atari16 Digest Tuesday, August 22, 1989 Volume 89 : Issue 402 This weeks Editor: Bill Westfield Today's Topics: Re: Multitasking on the ST QINDEX15 measurents : QuickST 1.46 vs TurboST 1.2 Re: Apathy and Defeatism Re: Loyal Atarians?!? Re: Multitasking on the ST Re: C.E.K.A. X windows modedit file(s) Screen flicker, top Re: Multitasking on the ST User needed near New Britain, CT RAM Upgrades ---------------------------------------------------------------------- Date: 14 Aug 89 04:29:46 GMT From: cwjcc!dsrgsun.ces.cwru.edu@g.ms.uky.edu (Jwahar R. Bammi) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <89081310545051@masnet.uucp>, david.megginson@canremote (DAVID MEGGINSON) writes: >From what I've heard, Minix is very restrictive with memory. Each >program is allowed a maximum of 64k, and there is not VM paging. A cute >toy, but useless for anything but learning. >--- The restriction on memory is only on the Ibm-Pc version of minix. In ST-minix there is no such restriction. Its true that there is no virtual memory. IMHO it is a little bit more than a cute toy. -- bang: any internet host!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi ------------------------------ Date: Mon, 14 Aug 89 11:28 N From: Subject: QINDEX15 measurents : QuickST 1.46 vs TurboST 1.2 To: info-atari16@score.stanford.edu X-Original-To: info-atari16@score.stanford.edu, KRUYSBERGEN To complete the QINDEX15 measurements I've compared QuickST 1.46 and TurboST 1.2. These two only affect the BIOS operations, so I'll give you these results only. All measures were done with a 1040ST with no accessories or AUTO folder programs (except QSTAUTO.PRG...) Normal QuickST TurboST BIOS character output 99 150 312 BIOS string output 99 578 725 BIOS text scrolling 99 175 178 GEM resource drawing 99 167 125 Psychological data: a difference between 578-725 is not 3.5 times the difference between 167-125! The ratio 725/578 = 1.25 and 167/125 = 1.31, so these differences are about the same. 578 is however 5.78 as fast as a normal 1040ST! The difference 167-125 is very noticeable. GEM resources are drawn much quicker. This favours QuickST. The difference 578-725 is pure mathematical, since the increase in speed of 578% in the QuickST case is already striking enough! Another increase up to 725 is merely 'for the record': this is hardly noticable in reality. Conclusion: the measures indicate a better BIOS text handling by TurboST and a better GEM resource handling by QuickST. These measures however have to be seen in the light of the human, indicating that QuickST is (in the comparison of these two versions) preferable. I'm not in the possession of QuickST 1.5 (witch should even be faster), nor am I in the possession of TurboST 1.6 (yet?). The new TurboST should handle GEM drawing much better one promissed to me... Noud van Kruysbergen N.I.C.I. Mail Box 9104 6500 HE Nijmegen The Netherlands kruysbergen@hnykun53 P.S. I haven't done any QINDEX15 testing using cache programs, since these programs keep the last information used in RAM. Reading the same infor- mation 64 times increases the QINDEX measure considerable, but this is not real! You'll never read the same information more than once normally, so unless your cache memory is rather big you'll never reach this measure in practice! Using a cache with these kind of measurements is one of the pitfalls I mentioned the first time. ------------------------------ Date: 14 Aug 89 01:00:39 GMT From: portal!cup.portal.com!Xorg@uunet.uu.net (Peter Ted Szymonik) Subject: Re: Apathy and Defeatism To: info-atari16@score.stanford.edu Hi Scott, although I completely agree with most of what you wrote, one falining among most people who bad-mouth the ST is not recognizing that unlike the Apple or MS-DOS machines, the ST was sold internationally and like it or not, the United States was never tapped as the major market for the ST. Yes, Atari has been brain-dead when it comes to the U.S> market, but that may well have been on purpose - going after and against MS-DOS and MAC's with the multi-BILLION dollar war-chests would hardly have been a wise business decision on the aprt of Atari. Atari's strategy HAS also worked by the way - financially the company is very strong and solid and 400 on the Fortune 500 list - far from an easy achievement for a compnay that appeared a mere four years ago! ------------------------------ Date: 14 Aug 89 09:01:49 GMT From: amdahl!pacbell!pbhya!dbsuther@ames.arc.nasa.gov (Daniel B. Suthers) Subject: Re: Loyal Atarians?!? To: info-atari16@score.stanford.edu The Question; Why are Atari users so fanatical/loyal? The ST was the best machine available at the time; Cheap, fast, capable. It is still fast and capable. Most of the software has been written from scratch, and takes the hardware into account. This makes for some VERY good programs. The IBM and MAC programs I have to work with generally are barely usable or badly over-priced. I would hate to have to put up with them at home. The built in interfaces mean that most programmers can devote time to the programing, not on getting it to work with all 10,000 variations of dos/memory/hardware/TSRs. The development environments are close enough the UNIX environment that I can port code to my ST, and back to the Mini I use at work. This saves me development time. I'd rather have a 3B4000, but can't aford the power bill. :-) Dan ------------------------------ Date: 14 Aug 89 08:10:39 GMT From: amdahl!pacbell!pbhya!dbsuther@ames.arc.nasa.gov (Daniel B. Suthers) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <63138@linus.UUCP> rachamp@mbunix (Champeaux) writes: >From The Amiga ROM Kernel manual: > > Every task has an assigned priority and tasks are scheduled to use the > processor on a priority basis. The highest priority ready task is selected > and receives processing until: > [TEXT DELETED] > Task scheduling is preemptive in nature. The running task may lose the > processor at nearly any moment by being displaced by another more urgent > task. Later, when the preempted task regains the processor, it continues > where it left off. > >When a higher priority task becomes active, the running task is immediately >interrupted. After reading this a question popped into my head. If you are downloading in the back ground (it seems the most popular multi-task task) and running a action game in the foreground, do you set the download process to the highest priority to avoid losing data or do you just put up with longer download times and connect times so your joy-stick will be responsive? While I'm at it... What is a "ray trace" that most amiga users seem to want to generate them, and are willing to wait 2 or 3 days for the output??? The ray traces I've done have always completed over-night, and that's longer than I wish to wait for a pretty drawing. My idea of great uses for multi-tasking agrees with the UNIX system. Utilities such as UUCP, LP and cron are great. I almost never compile in the back-ground as it adds just that much more time before it's finished, and I find myself constantly checking to see if it's finished yet. Dan Suthers, Analyst, Pacific Bell ------------------------------ Date: 10 Aug 89 16:10:20 GMT From: att!mtuxo!mtgzz!drutx!druwy!dlm@ucbvax.Berkeley.EDU (Dan Moore) Subject: Re: C.E.K.A. To: info-atari16@score.stanford.edu in article <8908091425.AA09465@ucbvax.Berkeley.EDU>, AKISUJAR@NUSVM.BITNET says: > Micheal C Barnes ask about CEKA Enterprises Phone Number. Here it is: > (415) 4742641 For benefit of the other netter who maay not aware what > this is all about, CEKA Enterprises is now working on the internal > hardware board for the MEGA and the forthcoming Stacey laptop to > emulate Macintosh with out the need for the Macintosh boot ROMs. I > only have the phone number of this company. I would appreciate the > Mailing address if you manage to contact them. The foundeer of this > firm is James McHugh. Unfortunately this is a hoax. There is no C.E.K.A Enterprises. James McHugh is someone who decided it was time for his 15 mintues of fame. James McHugh showed up on GEnie a few months ago and announced that he was going to be releasing a clone of the Macintosh OS ROMs and that his hardware/software would let Atari STs, Amigas, Apollo and Suns (I'm probably forgeting some, he listed almost every machine that uses a 68000 family CPU) all run Macintosh software. He promissed to send lots of people prototypes, and agreed to show up and do several demos. I've heard that several magazines even published his comments and lauded him for his programming skill (they did this without even seeing a prototype, which shows how real things in magazines are). Then people who know how the Macintosh works started asking him questions and he was unable to answer them correctly. He had no idea how the Mac works and what is needed to make non-Apple hardware work like a Mac. Soon after the questions started he disappeared, his phone, the one given above, was disconnected. No one has heard from him in a couple of months. If you like conspiracies you can believe that big evil Apple did away with him. Maybe they moved him in with Jimmy Hoffa. It's much more likely that he was a kid who wanted to be famous and get lots of attention, and now he's gone back to his normal, boring, life. If people are interested in running Macintosh software on the ST, or other computers, contact one of the real companies (eg. Gadgets by Small or ReadySoft). Don't waste your time on James McHugh. Dan Moore AT&T Bell Labs Denver dlm@druwy.ATT.COM ------------------------------ Date: Mon, 14 Aug 89 14:30:58 BST From: Mark Powell Subject: X windows To: Atari mailing list I've heard that there's an X-windows package that runs on the Megas. Is this true? If anyone knows anything about this could they e-mail me with the info. Thanks in advance. Mark Powell ARPAnet : sq79%liv.ac.uk@ucl-cs.arpa,cs.ucl.ac.uk USENET : ...!mcvax!ukc!liv.ac.uk!sq79 ------------------------------ Date: 14 Aug 89 09:12:29 GMT From: otter!gjh@hplabs.hp.com (Graham Higgins) Subject: modedit file(s) To: info-atari16@score.stanford.edu I'm trying to use to German modula-2 environment, but keep getting told that it can't find the editor. I somehow missed getting a specific file - modedit - from what was volume5 in the ssyx binaries archives. Could anyone email it to me? BTW, are the files that used to be in ssyx available anywhere else? - I had a look round but couldn't find modedit anywhere. Cheers, Graham ====== ------------------------------------------------------------------ Graham Higgins @ HP Labs | Phone: (0272) 799910 x 24060 Information Systems Centre | gray@hpl.hp.co.uk Bristol | gray%hplb.uucp@ukc.ac.uk U.K. | gray@hplb.hpl.hp.com ------------------------------ Date: 14 Aug 89 13:01:09 GMT From: romeo!currier@cs.duke.edu (Bob Currier - DCAC Network Comm. Specialist) Subject: Screen flicker, top To: info-atari16@score.stanford.edu Greetings, This weekend, while noodling around with animation, I came across a most puzzling phenomena. My graphics displayed fine while on the lower part of the screen (I am using a monochrome 1040), but when my little critters got about 30 or 40 pixels from the top they started to get a bad case of the flickers. I was using Vsync() to control flicker, and it seemed to work well, except for this twilight zone. I pulled my hair out for a couple of hours on this one, dug thru all my books, and finally, at about 1 a.m., in the premier issue of START, found a comment in an article about al graphics that went like this: "...vsync, but you will still see flicker near the top of the screen. This is a problem that can only be dealt with by very complex multiple screen flipping techniques..." So, does anyone know of this problem? What causes it? And, Virginia, how can I eliminate it? Bob Currier currier@romeo.cs.duke.edu rdc@northlab.ac.duke.edu ------------------------------ Date: 14 Aug 89 06:17:03 GMT From: mcvax!hp4nl!phigate!philmds!leo@uunet.uu.net (Leo de Wit) Subject: Re: Multitasking on the ST To: info-atari16@score.stanford.edu In article <194@crash.cts.com> fgbrooks@.UUCP (Fred Brooks) writes: |In article <1069@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: |>[about avoiding block in read/write on slow devices] | |I intercept the BIOS trap vector and add my own routine to do the BConin |call. If nothing is waiting in the buffer then I swapout the current process |, if a char is is the buffer it is passed on to the calling process and a |countdown variable is set to say 100 so that when then next time the buffer |is empty it won't swapout until it has checked the buffer a few times. You'll have to be careful this BIOS call was not done from GEMDOS, I think. I'm interested to know how you save a process's state. |>P.S. The current version screamed for job control, signalling etc. so |>that's being implemented right now (together with some system calls |>like signal() and kill()). | |I would like a copy if you are giving it away with source. The signalling stuff has been implemented. Now of course add job control, so that a character typed from the keyboard (~Z or is that too overloaded in GEMDOS?) can stop a process. I'll have to add a notion of background/ foreground, so that a background process is stopped when it wants to use the console (read/write) and can be brought into the foreground. You can have a premature copy if you want that (undoubtedly with bugs); before I offer it to the sources/binaries groups I want to test it myself when it is complete (I'm already thinking about pipes / interprocess communication etc., so depending on whether this would come into the first release, it could take a while). Leo. ------------------------------ Date: 14 Aug 89 14:18:09 GMT From: cs.dal.ca!silvert@uunet.uu.net (Bill Silvert) Subject: User needed near New Britain, CT To: info-atari16@score.stanford.edu A German colleague of mine is spending a half-term working at Central Connecticut State University in New Britain, CT. He needs to get his hands on an ST, but cannot find one at the university. Since he is developing a very interesting object-oriented modelling program (similar to Stella on the Mac, but much more sophisticated), I hope that someone in the area might be interested in contacting him. His name is Wolfgang Ebenhoeh, and he is in the Math/CS department at CCSU. His home telephone number is (203)224-2024, and he will be there until Christmas. I've worked with Wolfgang for a number of years, and he is an amazing and interesting fellow. If you contact him, you may want to ask about his computer version of Ecolopoly, a simulation of running a country in an environmentally acceptable fashion, written in OSS Pascal. -- Bill Silvert, Habitat Ecology Division. Bedford Institute of Oceanography, Dartmouth, NS, Canada B2Y 4A2 UUCP: ...!uunet,watmath!dalcs!biomel!bill Internet: biomel@cs.dal.CA BITNET: bs%dalcs@dalac.BITNET ------------------------------ Date: 14 Aug 89 14:20:21 GMT From: att!cbnewsm!cbz@ucbvax.Berkeley.EDU (craig.b.ziemer) Subject: RAM Upgrades To: info-atari16@score.stanford.edu I recently posted a request for info on the EZRAM II RAM upgrade board and received no replies. So, let me rephrase the question. Can anyone send me any information (opinions, etc.) on ANY RAM (1M) upgrade boards available? I'd like to checkout this possibility before I try the DIY piggyback-type upgrade. Suggestions appreciated! * Craig B. Ziemer %% DISCLAIMER: AT&T does not * * AT&T Bell Laboratories %%%%%% officially support what I * * Reading, PA %% just said, in fact, they * * UUCP ADDRESS: alux6!cbz %% rarely do :~) * ------------------------------ End of Info-Atari16 Digest ************************** -------